All committers have signed the CLA.

seems I didn't completely cover this in my unit test, stand by...

I'm on the fence as to whether I should be using pressure_weighted_mean or weighted_continuous average for the "cloud-layer winds". The original paper describes "a vector that represents cell advection by the mean cloud-layer wind (with “cloud layer” taken to be the 850–300-hPa layer)1" (Corfidi 2003) but then uses (wind_at_850+wind_at_700+wind_at_500+wind_at_300)/4 to estimate this.

Thinking more on this, this seems to weight the winds at higher pressures more, so maybe I should switch? It doesn't make a huge difference...

@wx4stg Just wanted to let you know that I have been looking at this when I have the cycles and been trying to figure out how I want to proceed on the "cloud-layer winds" problem.

yeah--no problem, I meant to attend last week's dev call but forgot (oops), but I plan to start attending those once the semester gets going.

Okay, so I've dug into this a bit and have attempted to reproduce the values produced in the paper and have not been able to do so (although very close in most circumstances), even with implementing their form of averaging for the cloud layer wind. My best guess is that the LLJ wind is the cause of the differences I'm seeing. I was not able to get the same value they propose for the 16 August 1997 case using either the 850-hPa LLJ method or the maximum wind in the lowest 1500 m.

My thoughts at this point are that the pressure weighted average is likely better. SharpPy averages the winds over the lower 1500 m for the LLJ and also implements non-pressure weighted averaging for both the LLJ and the cloud layer winds.

@mwilson14 Thoughts since you have thought about a lot of sounding indices in the past.

Okay, here is the latest of what I have found when working to compare to the table provided in Confide (2003) with the current version of the implemented vector in the PR. In general, it doesn't match the values in the paper, but is close for some soundings, reasonable for many more, and closer to the observed values in other instances. I tried a couple of variations with only using the four levels and using a mean wind for the LLJ and all of those combinations made the errors greater. The only difference that was fairly small and zero in a number of cases was using the 850-hPa wind for the LLJ instead of the max wind in the lowest 1500 m. My best guess as to the differences is that unique LLJ vectors were used for different cases.

I think we should implement a method within the function to be able to specify a particular LLJ u and v-component to override the default behavior. I think it is an open conversation whether to use the maximum in the lowest 1500 m or just the 850-hPa wind for the LLJ. If we do the latter, then we could reduce the need for the height as an extra input variable - though this would not be fully in line with the what the paper describes as a best practice.

Note: I used Wyoming Sounding Archive and had to change the station name for

• 87081912 OMA to OVN
• 89070212 OKC to OUN
• 89071712 OKC to OUN
• 90052800 SIL to LCH
• 91040912 LIT to LZK

This implementation makes sense to me! I agree that the pressure-weighted wind is likely better and that having an option in the function to specify a LLJ vector is a good idea. Also, sorry for missing that first comment I was tagged in, that was the weekend I moved to Boulder so things were a bit chaotic.

@wx4stg, okay so I think we have a final recommendation on implementation for this PR!

1. Add in an input option for a u and v LLJ. This will allow a more nimble method for end users who might know or want to specify a certain LLJ instead of using the default option that is implemented in the function.
2. Instead of using the maximum in the lowest 1500 m, to use the maximum wind from the surface to 850 hPa. This would allow us to reduce the number of input variables for users and not change the default value coming out of the function too much.
3. Put a second example in the function that demonstrates finding the maximum LLJ in the lowest 1500 m and putting that LLJ value in the optional variables.

Let @dcamron or I know if you would like any help or want to punt any of these updates to us if you don't have the cycles at the midpoint of the current semester.

@kgoebber thanks for the review! I have a few questions..

Add in an input option for a u and v LLJ. This will allow a more nimble method for end users who might know or want to specify a certain LLJ instead of using the default option that is implemented in the function.

Ok, just to clarify, I'll add keyword args, something like llj_u and llj_v, which are None by default. If the function is called without specifying, then proceed to find LLJ as maximum below 850 hPa?

Instead of using the maximum in the lowest 1500 m, to use the maximum wind from the surface to 850 hPa. This would allow us to reduce the number of input variables for users and not change the default value coming out of the function too much.

I agree with the idea of using pressure coordinate height for this, but this introduces a bit of an edge case: what if the sounding is from something like Denver where the surface pressure occasionally dips below 850 hPa? Raise ValueError? High altitude MCSes are... certainly not very typical, but just curious about how to handle this.

Let dcamron or I know if you would like any help or want to punt any of these updates to us if you don't have the cycles at the midpoint of the current semester.

Hilariously, these updates could not have come at a better time, we just finished midterms so I have a little breathing room this week :)

@kgoebber thanks for the review! I have a few questions..

Add in an input option for a u and v LLJ. This will allow a more nimble method for end users who might know or want to specify a certain LLJ instead of using the default option that is implemented in the function.

Ok, just to clarify, I'll add keyword args, something like llj_u and llj_v, which are None by default. If the function is called without specifying, then proceed to find LLJ as maximum below 850 hPa?

Yep! So in the end it should be something like...

def corfidi_storm_motion(pressure, u, v, *, u_llj, v_llj):

@dopplershift, @dcamron thoughts on naming of LLJ u and v components?

Instead of using the maximum in the lowest 1500 m, to use the maximum wind from the surface to 850 hPa. This would allow us to reduce the number of input variables for users and not change the default value coming out of the function too much.

I agree with the idea of using pressure coordinate height for this, but this introduces a bit of an edge case: what if the sounding is from something like Denver where the surface pressure occasionally dips below 850 hPa? Raise ValueError? High altitude MCSes are... certainly not very typical, but just curious about how to handle this.

I think raise a value error would be good and prompt to specify an LLJ u and v component. @dopplershift @dcamron thoughts?

Let dcamron or I know if you would like any help or want to punt any of these updates to us if you don't have the cycles at the midpoint of the current semester.

Hilariously, these updates could not have come at a better time, we just finished midterms so I have a little breathing room this week :)

Excellent! Hope midterms went well!

def corfidi_storm_motion(pressure, u, v, *, u_llj, v_llj):

@dopplershift, @dcamron thoughts on naming of LLJ u and v components?

While we usually try to avoid terse/abbreviated names so that the function is more self-documenting, u_low_level_jet seems a bit verbose and ugly for something we are requiring as a keyword argument, so I think I'm ok with eg. u_llj--we just of course have to spell out "low-level jet" when documenting what these are.

Instead of using the maximum in the lowest 1500 m, to use the maximum wind from the surface to 850 hPa. This would allow us to reduce the number of input variables for users and not change the default value coming out of the function too much.

I think raise a value error would be good and prompt to specify an LLJ u and v component. @dopplershift @dcamron thoughts?

Agreed. Something like ValueError("Unable to automatically determine low-level jet winds, please pass them in manually with u_llj and v_llj.)

@kgoebber I think this covers the requested changes and provides tests, if you still have the code from your earlier comparison, you can try it again.

strangely I can't get the bots to run..

There is a conflict with the main branch. There are a couple of ways to resolve the conflict. In general it is best of you update your main MetPy branch

git checkout main

git pull upstream main

git checkout <branch>

git rebase -i main

The last command is the rebase in an interactive mode. It will notify you if there are conflicts that are not resolved automatically that might need your intervention. Once you have rebased, then you can push the branch updates as per usual.

I see. I wasn't sure if y'all would want to handle that or not. thanks.

Thanks for working with us on getting this in @wx4stg !